Timers are widely used in communication networks to supervise communication procedures and signaling exchange between entities of the communication network based on protocols. An example of such entities may be a Call Session Control Function, CSCF, being an essential node in an IP Multimedia System, IMS, for processing signaling, using a Session Initiation Protocol, SIP, as the signaling protocol. CSCF handles session establishment, modification and release of IP multimedia sessions using the SIP/Session Description Protocol, SDP, protocol suite. A 3rd Generation Partnership Project, 3GPP Technical Specification, TS 23.228 describes logical nodes Proxy P-CSCF, Interrogating I-CSCF, Serving S-CSCF, Emergency E-CSCF and Border Gateway Control Function, BGCF.
The S-CSCF conforms to 3GPP TS 24.229 specification and performs the session control services for a User Equipment, UE. It maintains a session state for support of the services requested by and offered to the UE.
The S-CSCF performs for example the following functions:                Acts as a registrar according to RFC3261 at registration        Notify subscribers about registration changes        Session control for the registered user's sessions        Handles SIP requests and services them internally or forwards them        Interaction with application servers        
An S-CSCF performs SIP routing according to the 3GPP routing procedures.
RFC 3261 defines SIP timers for supervising the lifetime of a transaction within the network. Dependent on what type of request (non-INVITE or INVITE request) or response (successful or not successful) and what type of transport protocol is used (User Datagram Protocol, UDP or Transmission Control Protocol, TCP) different SIP timers are used.
Following SIP transaction timers are applicable within the CSCF:                Timer T1—Round-Trip Time estimate        
Timer T1 is used to supervise transactions at UDP transport. The timer is configurable. The value shall be the estimated round-trip time. CSCF does not directly use T1 as a timer, T1 is instead used to calculate the timers A, B, E, F, G, H and J.                Timer T2—Maximum retransmit interval for non-INVITE requests and INVITE responses        
Timer T2 defines the maximum retransmission interval for non-INVITE requests and INVITES responses. The T2 value is used as a maximum value for timer E and timer G.                Timer T4—Maximum duration a message will remain in the network        
Timer T4 defines the maximum duration a message will remain in the network. The timer is configurable. The value T4 is used as a value for timer I and timer K.                Timer A—INVITE request retransmit interval for UDP only        Timer B—INVITE transaction timeout timer        Timer C—Proxy INVITE transaction timeout        Timer D—wait time for response retransmits        Timer E—non-INVITE request retransmit interval for UDP only        Timer F—Maximum waiting time for final response for a non-INVITE transaction        Timer G—INVITE response retransmit interval        Timer H—wait time for ACK receipt after 3xx-6xx SIP responses        Timer I—wait time for ACK retransmits        Timer J—Maximum waiting time for request re-transmits for a non-INVITE request        Timer K—Waiting time for response retransmits for non-INVITE requests        
Timers are started hop-by-hop at each entity that needs to keep track of a transaction.
In IMS using SIP as mechanism of signaling communication, transactions are monitored hop-by-hop by the entities that are involved in the communication chain. This means that timers are started for different type of information to be sent or received to keep track of the valid lifetime, so re-transmission or canceling of the transaction can be performed as appropriate.
In the communication between entities there could be several entities included and each of them has own timer settings local to the specific entity. Relations in timer settings between entities are usually configured and coordinated manually and there is no logic in the entities of informing its own peers what they will use for a given communication procedure.
As between entities, entities keep track of their own timers only, communication procedures can get out-of-sync for communication traversing a network and timers time-out in one entity within the chain before the response has been received.
There could also be race condition occurring when timers are expired and communications related to the same sessions are competing through the network to reach its destination.
In large networks with multiple destinations as alternative routing paths, timer relations really matters if the configured paths will ever be tried before the timer in previous hops expired.
For services involving serial forking of communication to multiple contacts the timer knowledge is of interest to know how long it is sufficient to wait before canceling a request. In a worst case, a new forking is done at a remote entity, although a local timer for the related communication procedure has expired already.